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Abstract 


The  1998  UK  Strategic  Defence  Review  (SDR)  introduced  Smart  procurement  (now 
Smart  Acquisition)  to  transform  both  the  mechanisms  and  the  values  of  equipment 
procurement  within  defence.  This  initiative  combined  a  revised  procurement  process, 
encouraging  novel  contractual  relationships,  and  a  move  to  whole-life  management. 
Five  years  on,  the  UK’s  National  Audit  Office  has  reported  improvements  in  gross 
time  and  cost  overrun  on  major  projects,  but  states  that  “there  is  more  to  do”  -  further 
improvements  are  required  in  the  way  that  large  procurement  programmes  are 
managed  and  run. 

In  this  paper  we  focus  on  some  areas  in  which  “more  needs  to  be  done”  and  “more  is 
being  done”  to  deliver  the  SDR  vision.  The  areas  addressed  include: 

4-  Methodologies  and  architecture  frameworks  for  defining  and  managing 
requirements. 

4-  Engaging,  motivating  and  improving  the  performance  of  stakeholders  in  the 
acquisition  process  through  transparency,  incentive  and  communication. 

This  paper  summarises,  demonstrates  and  illustrates  the  methodology  and  tools  that 
we  are  developing,  and  aligns  our  approach  and  experiences  with  improvements  in  the 
effectiveness  of  defence  procurement.  It  argues  that  the  DoD  AF  paradigm  is  not 
sufficient,  and  that  real  improvement  implies  the  need  for  action  at  both  technical  and 
business  levels. 

1.  Introduction 

One  of  the  principal  outcomes  of  the  1998  UK  Strategic  Defence  Review  (SDR)  was 
the  introduction  of  Smart  procurement  (now  Smart  Acquisition),  aiming  to  transform 
both  the  mechanisms  and  the  values  of  equipment  procurement  within  defence,  to 
achieve  both  cost  savings  and  performance  improvements:  “faster,  cheaper  and 
better”.  The  initiative  combines  a  revised  procurement  process,  with  novel 
contractual  relationships  and  a  move  to  whole-life  management  to  introduce 
partnering  and  incremental  acquisition,  and  to  control  defence  inflation. 
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Five  years  on,  the  UK’s  National  Audit  Office  (NAO),  monitoring  the  performance  of 
the  initiative1,  has  reported  improvements  in  gross  time  and  cost  overrun  on  the  new 
Smart  projects,  but  notes  that  “there  is  more  to  do”.  While  there  are  encouraging 
signs  of  more  innovative  relationships  with  industry,  improvements  are  still  required 
at  the  basic  level  of  how  large  procurement  projects  are  managed  and  run.  As  noted 
in  the  UK  NAO  report,  even  Smart  projects  are  £400  million  over  costs  and  61 
months  over  original  forecast  at  Main  Gate  (see  Figure  1  for  an  overview  of  the 
relevant  parts  of  the  Smart  Acquisition  -  “CADMID”  -  process). 


Figure  1.  The  Stages  and  review  “Gates”  within  the  UK  MoD’s  Smart  Acquisition  process 


In  this  paper  we  focus  on  some  specific  areas  in  which  “more  needs  to  be  done”  and 
“more  is  being  done”  to  deliver  the  SDR  vision,  including: 

4-  Methodologies  and  architecture  frameworks  for  defining  and  managing 
requirements;  de-risking  development  through  improved  coherence, 
integration  and  communication. 

-4-  Engaging,  motivating  and  improving  the  performance  of  stakeholders  in  the 
acquisition  process  through  transparency,  incentive  and  communication. 


A  pre-requisite  for  success  in  large-scale  procurement  is  the  definition  of  expressive 
and  coherent  user  requirements  at  the  outset,  together  with  a  methodology  that 
enforces  continued  traceability  of  subsequent  development  against  this.  Informal  or 
weak  requirements  add  considerably  to  development  risk,  manifest  through 
disconnected  design  and  manufacture  activities,  in  turn  leading  to  ineffective 
solutions,  contractual  complications  and  expensive  re-work. 


This  observation  is  confirmed  in  the  findings  of  the  UK  NADy^^f: 
continues  to  govern  the  initial  appraisal  of  projects  and  there  are  p^e 

not  always  sufficiently  understood  when  committing  to  the  maii^nvBstmmtat  Mwc  r 
Gate.  The  costs  and  in-service  dates  for  more  than  two  thirds  (tfpfqjecisncwe  arpiea 

Initial  Gate  approval 


l  UK  National  Audit  Office,  “MoD  Major  Projects  Report  2003”,  Report  by  the  Comptroller  and  Auditor  General,  HC  195 
Session  2003-2004:  January  2004. 
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away  from  those  planned  (50  per  cent  estimates)  towards,  and  in  a  very  few  cases 
beyond,  the  highest  acceptable  approved  limits  (90 per  cent  estimates )” 

Although  a  necessary  component,  this  is  not  in  itself  sufficient  to  ensure  the  levels  of 
effectiveness  envisaged  within  the  SDR:  there  are  also  important  considerations  of 
programme  methodology  and  contract  management.  The  UK  NAO  Report  observes 
that  “ The  variations  on  some  Smart  projects  indicate  that  there  are  a  range  of  cultural 
and  systemic  influences  which  the  Department  and  its  industry  partners  need  to 
manage  to  deliver  projects  successfully .” 

In  this  paper  we  summarise,  demonstrate  and  illustrate  the  methodology  and  tools  that 
we  are  developing,  and  align  our  approach  and  experiences  with  requirements  for 
improvement  in  the  effectiveness  of  defence  procurement.  We  argue  that  real 
improvement  implies  the  need  for  action  at  both  technical  and  business  levels,  and 
also  that  these  different  perspectives  are  more  closely  connected  than  is  generally 
appreciated.  In  particular,  the  development  and  deployment  of  enterprise  architecture 
frameworks  needs  to  extend  beyond  the  technical  domain  if  it  is  to  achieve  the  desired 
outcome.  The  US  Department  of  Defense  Architecture  Framework  (DoD  AF)  is 
being  proposed  as  a  basis  for  UK  improvements.  We  argue  that  this  in  itself  is 
insufficient  to  deliver  the  ambitious  goals  of  the  SDR  because  it  does  not  address  the 
real  needs  for  increased  business  input  and  engagement  within  the  process. 

This  paper  first  describes  in  more  detail  the  problem  space  and  proceeds  to  present 
some  observations  of  shortcomings  in  current  practice.  We  then  describe  and 
illustrate  some  of  the  key  aspects  of  our  proposed  approach,  before  summarising  our 
argument  and  presenting  our  conclusions. 


2.  The  challenges  to  be  addressed 

In  this  section  we  describe  in  more  detail  the  problem  space  that  we  are  addressing  in 
terms  of  key  challenges  that  must  be  faced  to  deliver  the  SDR  goals,  and  specific 
requirements  that  are  implied. 

2.1  Creating  a  common  language  to  enable  effective  engagement  of  stakeholders 

Addressing  major  acquisition  programmes  is  a  fundamentally  challenging  task, 
requiring  us  to  manage  the  evolution  and  development  of  an  integrated  set  of  common 
pictures  of  an  enterprise  that  are  meaningful  to  the  perspectives  of  many  different 
people.  These  common  pictures  need  to  communicate  at  many  levels  and  in  many 
ways.  At  one  level  we  need  pictures  to  explain  contextual  relationships  and  to  set 
broad  expectations  of  effect;  at  another  level  we  need  pictures  that  describe  the 
associated  “business”  stakeholder  responsibilities  of  the  programme;  and  at  a  much 
lower  level  we  need  pictures  that  can  be  subject  to  analysis  of  quality  and  stress. 

The  complete  architecture  of  any  sizeable  programme  will  typically  run  into  many 
hundreds  or  even  thousands  of  such  pictures.  These  are  of  limited  (and  possible 
negative)  utility  unless: 
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4-  The  pictures  really  are  integrated  -  in  that  they  fit  together  so  that  changes  in 
one  perspective  or  at  one  level  ripple  through  other  aspects  of  the  architecture 
that  is  affected  by  the  changes. 

4-  The  pictures  really  are  common  -  in  that  they  enable  a  single  understanding  to 
be  communicated  across  the  communities  of  stakeholders,  where  changes 
initiated  by  one  community  are  reflected  in  the  other  perspectives. 

4-  The  pictures  address  the  breadth  of  perspectives  needed  to  synchronise  and  co¬ 
ordinate  the  development  of  the  required  capability. 

Imagine  looking  at  something  from  60,000  feet.  Then  change  your  perspective  so  you 
see  just  part  of  this  picture  from  6  feet.  A  representation  that  works  for  components 
that  are  a  long  way  off  may  not  work  when  trying  to  understand  the  detailed 
requirements  for  integration  of  this  component  with  other  equipment  in  the  field  (see 
Figure  2). 


Capability  Requirement  High-level  Operational  View 


The  Operational  Concept  of  Conduct  Joint  Force  Targeting 

m 


Viewed  at  the  60,000  foot 
perspective,  we  are  aware  of 
the  overall  context  of  the 
requirement,  and  the 
principal  participating 
components 


Viewed  at  the  6  foot 
perspective,  we  are  able  to 
analyse  the  specific 
interactions  required  between 
specific  components  in  order  to 
achieve  connectivity  and 
synchronisation 


of 


USCENTCOM  Targeting  MEA  OV-6c 


Detailed  Operational  View 


The  challenge  is  to  ensure  integrity,  breadth  and  completeness 
these  views,  to  inform  and  connect  a  broad  community  of 
stakeholders  actively  throughout  the  programme 


Figure  2.  The  challenge  of  achieving  a  single  consistent  picture  that  is  meaningful  to  diverse 
stakeholders 


Moreover,  these  perspectives  need  to  be  accessible  and  meaningful  to  a  wide  range  of 
stakeholders,  including  people  whose  interests  cover  technical,  commercial, 
contractual  and  managerial  aspects  of  development.  For  example,  it  is  critical  to 
provide  a  perspective  to  allow  training  requirements  to  be  assessed  at  an  early  stage  to 
avoid  delays  on  achieving  an  operational  capability. 
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The  UK  NAO  Report  observes  that  “ Successive  Major  Projects  Reports  since  2000 
have  highlighted  the  need  for  the  Department  to  get  the  best  out  of  the  crucial  early 
Assessment  Phase  of projects  in  terms  of  understanding  and  reducing  risks  P 

Methodologies  and  notations  for  describing  and  analysing  requirements  must  not 
therefore  focus  solely  on  technical  perspectives;  otherwise  we  embed  at  an  early  stage 
the  risk  of  key  stakeholders  becoming  disengaged  from  crucial  decisions. 
Consequently,  the  original  vision  is  lost,  together  with  the  crucial  responsibility  for 
defining  key  aspects  of  the  required  effect.  This  disengagement  is  a  common  cause  of 
delays  and  expensive  re-work  later  in  the  process.  It  is  a  significant  contributor  to  the 
UK  NAO’s  observation  that  “risks  are  not  always  sufficiently  understood  when 
committing  to  the  main  investment  at  Main  Gate.  ” 

To  keep  key  stakeholders  engaged  through  the  crucial  early  stages  of  the  procurement 
process,  it  is  necessary  that  these  stakeholders  are  able  to  work  with  the  collection  of 
pictures  in  an  intelligent  and  absorbing  way,  and  also  that  these  stakeholders  take  the 
clear  responsibility  for  defining  what  it  is  that  they  need. 

The  challenges  introduced  above  have  diverse  implications.  These  are  summarised 
below  in  terms  of  three  key  requirements  for  improving  the  effectiveness  of  defence 
procurement: 

2.2  Defining  capability  requirements  independently  of  solution 

4-  We  need  a  process  for  managing  User  and  System  Requirements  that  is 
meaningful  to  the  owners  and  stakeholders  of  the  system,  while  at  the  same 
time  sufficiently  rigorous  to  enable  analysis. 

4-  This  process  needs  to  enable  agreement  and  debate  on  the  overall  vision  for 
the  capabilities  in  the  enterprise,  with  all  of  the  richness  around  where  the 
enterprise  is  now  and  where  it  is  heading. 

4  We  need  to  be  able  to  manage  requirements  as  a  set  of  principles  and 
constraints  that  exist  through  the  lifetime  of  a  set  of  capabilities  rather  than  as 
a  contractual  statement  created  by  and  for  the  benefit  of  technicians  and 
experts. 

4-  We  need  to  support  informed  Balance  of  Investment  decisions  such  that  the 
impact  of  those  decisions  on  the  delivery  of  military  capability  is  fully 
understood.  This  requires  an  understanding  of  the  interdependencies  of 
individual  requirements  and  their  contribution  towards  the  delivery  of  a 
particular  capability. 

2.3  Managing  communication  and  relationships 

4-  We  need  to  understand  the  contributions  of  and  relationships  between  the  key 
stakeholder  groups  of  specifier,  customer  (or  end  user),  procurer  and  supplier 
in  capability  development  and  delivery. 

4-  We  need  an  environment  in  which  both  the  military  and  industry  stakeholders 
can  communicate  and  share  throughout  the  procurement  process  at  all  levels 
from  vision  through  to  design. 
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4-  This  environment  needs  to  provide  a  mechanism  whereby  these  stakeholders 
keep  sharing  and  interacting  through  the  lifetime  of  the  components  that  are 
acquired  and  developed. 

4-  We  need  to  understand  the  difference  between  relationships  that  are  about  on¬ 
going  service  provision  and  those  that  focus  upon  development  and  handover 
of  capability,  and  manage  these  accordingly. 

2.4  Managing  performance  and  achievement 

4-  We  need  to  be  able  to  define  performance  across  all  the  views,  across  all 
components,  whether  these  are  technological,  organizational,  process-based, 
role-specific,  military  capabilities  or  pieces  of  equipment,  including 
performance-based  interaction  between  these. 

4-  We  need  to  be  able  to  define  metrics  that  apply  to  service  and  network-enabled 
capability  concepts  such  as  interoperability. 

i-  We  need  to  be  able  to  monitor  and  tune  the  performance  of  the  parts  and  the 
whole  over  time. 

4-  And  we  need  to  be  able  to  address  all  of  these  issues  without  burdening  the 
development  process  with  unacceptable  cost,  complexity  or  effort  overheads. 

3.  Shortcomings  in  Current  Practice 

In  this  section  we  consider  several  key  aspects  of  current  practice  within  the  context 
of  the  challenges  and  requirements  identified  previously.  We  address  four  specific 
aspects. 

3.1  Requirements  definition  is  conditioned  by  current  &  past  assumptions 

User  requirements  are  too  often  developed  within  the  assumptions  of  current 
experience.  This  means  that  at  the  outset,  a  new  capability  is  assumed  to  be  a  strike 
aircraft,  a  frigate  or  an  armoured  land  vehicle. 


The  consequences  of  this  tendency  are  that: 
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4-  At  the  only  point  in  the  process  where  there  is  licence  for  this  breadth  of 
innovation,  creative  alternatives  are  not  explored; 

V  Requirements  are  prematurely  expressed  in  terms  of  the  technical  solutions 
previously  applied  for  that  kind  of  equipment,  further  limiting  the 
opportunities  for  innovation  (see  Figure  3). 

3.2  The  coverage  of  key  areas  within  acquisition  stages  is  often  unbalanced 

Each  stage  in  the  acquisition  process  involves  considerations  of  various  kinds, 
including  the  technical,  the  organisational,  performance,  people  &  training,  and 
others.  Each  of  these  is  significant  to  one  or  more  of  the  stakeholders  participating  in 
the  process. 

The  coverage  of  these  considerations  is  often  unbalanced,  with  more  focus  in  certain 
areas  than  in  others  (See  Figure  4.) 


Technical 

considerations 

People  & 

training 

considerations 


Performance 

considerations 


A  number  of  considerations  apply  throughout  the  process, 
each  within  the  sphere  of  interest  of  one  or  more  stakeholders. 

The  balance  of  effort  given  to  these  considerations  throughout  the  process  is  important, 
to  enable  continuing  engagement  with  stakeholders. 


Figure  4.  The  need  to  balance  the  effort  applied  to  different  considerations  in  order  to  sustain 
stakeholder  engagement 


An  example  of  shortcoming  in  this  area  relates  to  the  UK  Apache  programme  which, 
following  difficulties  in  the  delivery  of  training  services,  will  not  now  be  completed 
until  February  2007,  nearly  3  years  later  than  expected.  Some  Apache  aircraft  will 
have  to  be  stored  until  trained  pilots  are  available  to  fly  them,  at  an  additional  cost  of 
£6  million2. 

3.3  Application  of  enterprise  architecture  methodology  over-emphasises  the 
technical 

Enterprise  Architecture  Frameworks  in  general,  and  DoD  AF  in  particular,  have 
emerged  in  response  to  these  kinds  of  challenges.  Although  the  concepts  have  been  in 
the  public  domain  for  many  years  (see,  for  example,  the  original  work  of  Zachman3), 


2  Ministry  of  Defence,  “ Building  an  Air  Manoeuvre  Capability:  The  Introduction  of  the  Apache  Helicopter ”,  Report  By  The  Comptroller  And  Auditor  General 
HC  1246  Session  2001-2002:  31,  October  2002 

3  John  Zachman,  “A  framework  for  information  systems  architecture ”,  IBM  Systems  Journal  Vol  26  NO  3,  1987 
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this  initiative  has  been  given  extra  impetus  in  the  US  by  the  1996  Clinger  Cohen  Act. 
Recognising  the  promise  of  this  approach,  interest  in  the  UK  is  accelerating. 

Enterprise  architectures  put  together  the  process  to  be  followed,  the  products  to  be 
created  and  the  way  these  are  to  be  used  in  such  a  way  as  the  whole  acts  as  an  anchor 
for  a  development  programme.  The  resulting  structure  is  intended  to  be  used  as  the 
basis  for  planning  and  decision  making  on  an  on-going  basis.  Gartner  have  cited  three 
main  justifications  for  enterprise  architecture: 

4-  Saving  costs  through  standardisation  and  reuse. 

4-  Allowing  the  improvement  of  business  processes. 

4-  Allowing  for  strategic  shifts  in  business  relationships. 

The  scope  implied  by  these  justifications  is  broad  and  consistent  with  Zachman’s 
original  vision.  However,  the  potential  benefits  of  this  approach  have  proved  elusive 
because  the  approach  poses  many  of  the  challenges  described  above  and  these  have 
not  fully  been  grasped.  All  too  often  enterprise  architecture  initiatives  create  different 
perspectives  on  one  project,  rather  than  facilitating  different  perspectives  across  one 
enterprise  containing  multiple  projects.  As  one  recent  commentator  working  within 
the  UK  MoD  has  observed: 

“Creating  individual  models  and  diagrams  is  not  the  hard  part  for  architecture 
-  in  practice  we  tend  to  know  already  what  many  of  the  components  are.  It’s 
getting  these  components  to  fit  together,  allowing  individuals  to  apply  their 
own  expertise  yet  help  to  make  sense  of  the  whole  that  is  the  real  challenge. 
Only  by  meeting  this  challenge  head  on  can  we  be  in  a  position  to  evolve  our 
systems  and  our  organisations  sufficiently  rapidly  to  achieve  the  kind  of  agile 
capability  that  the  modem  world  of  defence  demands.” 

In  other  words,  for  enterprise  architectures  to  be  effective,  it  is  important  that  both  the 
methodology  respects  the  real  requirements  of  the  enterprise,  and  that  the 
methodologies  and  tools  used  to  create  and  manage  the  architecture  allow  the  kinds  of 
coherence  of  expression  and  analysis  that  we  need  in  order  to  address  the  real 
challenges. 

3.4  The  social  and  economic  realities  of  acquisition  are  being  neglected 

Smart  Acquisition  and  Enterprise  Architecture  Frameworks  offer  attractive 
management  metaphors  for  defence  decision-makers.  But  these  metaphors  do  not 
make  decisions  and  they  cannot  be  evaluated  without  reference  to  the  motivations  and 
behaviour  of  individuals  and  groups  who  use  these  systems.  Here,  the  economics 
contribution  focuses  on  the  principles  of  self-interest  and  the  pursuit  of  beneficial 
exchange;  it  identifies  some  of  the  major  differences  between  the  public  and  private 
sectors  of  the  economy;  and  it  shows  the  role  of  uncertainty  and  the  costs  of 
contracting4. 

Efficiency  in  the  private  sector  results  from  competition,  the  pursuit  of  profits  by 
entrepreneurs  and  the  role  of  the  capital  market  as  a  ‘policing  and  monitoring’ 


4  Sandler  T  and  Hartley  K,  “ The  Economics  of  Defence",  Cambridge  University  Press,  Cambridge,  Chapter  5.  1995. 
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mechanism.  These  institutions  and  incentives  are  absent  from  the  public  sector.  In 
defence,  there  are  no  rival  Armed  Forces,  there  are  no  military  entrepreneurs  and  there 
is  no  capital  market  with  its  threats  of  take-over  and  bankruptcy. 

Smart  Acquisition  and  Enterprise  Architecture  need  to  recognise  that  they  involve 
various  interest  groups,  each  pursuing  different  objectives.  In  itself,  use  of  these 
metaphors  does  not  guarantee  that  people  will  work  together.  In  effect,  the 
approaches  create  a  complex  and  adaptive  set  of  human  relationships  with  massive 
opportunities  for  conflicting  objectives.  For  example,  Smart  Acquisition  embraces 
interest  groups  of  the  Armed  Forces,  the  Ministry  of  Defence  and  private  contractors 
(some  of  which  might  be  non-UK  firms).  The  Armed  Forces  require  modern 
equipment  at  affordable  prices  (given  limited  defence  budgets);  the  UK  MoD  seeks 
‘best  value  for  money’  which  includes  narrow  defence  criteria  as  well  as  wider 
industrial  and  economic  benefits  associated  with  procurement;  and  contractors  are 
seeking  profits.  The  challenge  is  to  recognise  these  conflicting  objectives  and  devise 
contractual  arrangements  that  will  provide  the  buyer  with  efficient  solutions.  Even 
this  simple  statement  of  the  procurement  problem  is  not  without  its  difficulties.  Who 
is  the  buyer  (the  Armed  Forces  or  the  MoD);  how  is  efficiency  defined  and  by  whom; 
which  type  of  contract  will  achieve  these  objectives;  and  how  are  contracts  to  be 
awarded  (competition  vs.  negotiation)? 

It  also  has  to  be  recognised  that  procurement  choices  take  place  in  a  world  of 
uncertainty  where  no  one  knows  the  future.  This  is  particularly  the  case  in  defence 
procurement  where  there  are  major  uncertainties  about  both  technology  and  the  future 
threat  often  involving  time-horizons  of  40-50  years  (e.g.  Trident;  Typhoon). 
Uncertainty  also  means  that  contracts  are  incomplete  since  it  is  not  possible  to  write  a 
complete  contract  which  anticipates  all  future  contingencies  (some  are  unknown  and 
unknowable). 

Smart  Acquisition  and  Enterprise  Architecture  are  not  costless  systems.  Like  all 
contracting,  they  involve  substantial  transaction  costs  and  there  are  always 
possibilities  of  unexpected  and  perverse  outcomes.  People  adjust  to  organisational 
and  policy  changes  and  can  play  any  games.  Transaction  costs  include  the  costs  of 
search,  negotiation,  agreement,  monitoring  and  enforcement  of  contracts;  and  since  no 
agreement  can  specify  all  possible  future  contingencies,  changing  contractual 
agreements  involves  substantial  transaction  costs5. 

Contracting  is  characterised  by  opportunism  and  ‘bounded  rationality’: 

4-  Opportunism  recognises  that  individuals  and  groups  will  take  advantage  of 
situations,  especially  when  the  terms  of  a  contract  are  vague  or  missing.  For 
example,  individuals  might  have  incentives  to  hoard  valuable  information  and 
such  hoarding  can  disrupt  information  flows  both  within  and  between 
organisations  and  agencies. 

4-  ‘ Bounded  rationality  ’  recognises  that  no  contract  can  cover  every  contingency 
in  an  uncertain  world:  people  have  bounded  rationality  in  the  form  of  a  limited 
ability  to  specify  all  future  possibilities  (states  of  the  world). 


5  Arrowsmith  S  and  Hartley  K  (eds),  “ Public  Procurement ”,  International  Library  of  Critical  Writings  in  Economics  144,  Elgar,  Cheltenham.  2002 


2004  CCRP  Research  &  Technology  Symposium 


Page  9 


Improving  requirement  modelling  and  traceability  within  an  enterprise  architecture  framework: 

methods,  blueprints  and  experiences  -  challenging  the  DoD  AF  paradigm 


Private  firms  use  incentives  to  encourage  efficient  behaviour  and  to  reduce  internal 
monitoring  costs  (e.g.,  performance-related  pay;  bonuses;  prizes,  etc).  Competition 
and  the  capital  market  also  provide  efficiency  incentive.  Ultimately,  entrepreneurs 
have  to  take  risks  and  make  decisions  and  success  is  rewarded  with  profits  and  failure 
results  in  losses  and  possible  exit  from  the  industry.  There  are  no  such  efficiency 
incentives,  mechanisms  and  entrepreneurs  for  the  MoD  and  Armed  Forces. 

The  implication  of  an  economics  approach  to  Smart  Acquisition  and  Enterprise 
Architecture  is  that  there  are  no  perfect  solutions.  All  organisational  arrangements  are 
flawed.  The  challenge  is  to  select  arrangements  which  minimise  the  flaws  and 
inefficiencies.  Here,  there  are  some  economic  principles  offering  policy  guidelines: 

4-  First,  competition  promotes  efficiency  amongst  contractors. 

4-  Second,  successful  contractors  need  to  be  subject  to  efficiency  incentives  in 
the  form  of  an  incentive  type  contract  (target  cost  incentive  or  firm/fixed  price 
contracts). 

t  Third,  the  procurement  agency  needs  to  be  clear  about  its  policy  objectives; 
about  the  ‘weights’  it  attaches  to  various  and  often  conflicting  objectives;  and 
it  need  to  recognise  that  in  an  uncertain  world,  these  objectives  and  hence 
equipment  performance  requirements  can  change  and  need  to  change. 

Competition  can  only  be  promoted  if  the  competing  elements  can  be  adequately 
described  and  understood.  Unlike  competing  solutions,  concepts,  policies  and 
incentives  cannot  so  readily  be  described.  And  this  is  an  area  where  Enterprise 
Architectures  have  a  valuable  contribution  to  make:  assisting  in  the  formalisation  of 
these  relatively  intangible  elements,  revealing  insights  about  the  choices  available,  as 
a  basis  for  rational  exploration  and  discussion. 


4.  Addressing  the  challenges:  methodology,  notations  and  tools 

Implementing  these  principles  and  addressing  the  other  challenges  for  acquisition  set 
out  in  this  paper  requires  thinking  rather  differently  about  methodology,  notations  and 
tools  than  their  historical  background  and  heritage  currently  allows.  In  this  section  we 
introduce  the  elements  of  our  approach  to  the  challenges  introduced  in  the  previous 
sections,  and  describe  its  application  to  a  current  area  of  capability  development. 

4.1  Principles  and  ideas  underlying  the  approach 

The  creation  of  methodology,  notations  and  tools  to  support  acquisition  and 
development  has  become  a  significant  industry  in  its  own  right  over  the  past  three 
decades,  drawing  influences  from  a  variety  of  sources,  such  as  operational  research 
and  software  development  methods.  The  approaches  that  have  been  developed  have 
been  predominantly  technical,  based  on  semi-formal  diagramming  notations  from  the 
computing  and  telecommunications  communities. 

While  meeting  with  a  degree  of  success  in  addressing  the  more  formal  development 
activities,  these  methods  and  tools  have  been  found  lacking  when  the  process  of 
development  and  acquisition  is  considered  from  a  whole-process  point  of  view  that 
encompasses  social  and  economic  realities.  Objections  revolve  around  the 


2004  CCRP  Research  &  Technology  Symposium 


Page  10 


Improving  requirement  modelling  and  traceability  within  an  enterprise  architecture  framework: 

methods,  blueprints  and  experiences  -  challenging  the  DoD  AF  paradigm 


observation  that  the  acquisition  process  is  ultimately  all  about  people  interacting  with 
other  people,  coming  to  a  shared  and  joint  understanding  of  the  situations  in  which 
they  each  hold  authority. 

This  key  observation,  memorably  described  by  Goguen6  as  the  need  to  reconcile  the 
‘wet’  with  the  ‘dry’  in  this  process,  has  not  received  the  recognition  that  it  deserves  in 
defence  acquisition,  despite  the  groundwork  being  laid  out  through  the  Smart 
Acquisition’s  CADMID  process  which  lays  the  framework  for  the  stakeholders, 
stages  and  perspectives  that  need  to  be  accommodated  and  supported  individually, 
and  in  interaction  with  others. 


Figure  5.  Multi-layer  requirements  for  engagement  of  stakeholders 


The  approach  the  authors  have  taken  in  addressing  these  challenges  has  been  to 
deploy  Salamander’s  MooD®  Transformation  Toolset  to  create  a  US  DoD  AF  based 
Transformation  Blueprint  that  encompasses  operational,  systems  and  technical 
standards  views,  plus  additional  capability  and  acquisition  views,  integrated  through 
an  open  underlying  repository.  The  toolset  has  been  developed  over  the  past  seven 
years  by  a  team  combining  experience  in  operational  research,  formal  requirements 
engineering,  software  development  and  operational  and  business  strategy,  and  has 
been  applied  in  a  wide  range  of  modelling  applications  spanning  many  industries, 
across  many  stakeholder  communities,  uniting  different  aspects  of  business  and 
technical  development  and  acquisition  problems. 

Allied  to  a  strong  and  flexible  underlying  repository,  the  MooD  toolset  has  enabled 
the  team  to  develop  a  blueprint  with  the  ability  to  display  the  key  themes  of 


6  J  Goguen  “The  Dry  and  the  Wet ”  Technical  Monograph  PRG-10,  Oxford  University  Computing  Laboratory,  1992 
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integration  and  coherence  across  the  changing  needs  of  the  acquisition  process,  as  it 
progresses  from  the  contextual  and  exploratory  to  the  deeply  technical  and 
contractual. 

The  blueprint  acknowledges  the  different  stakeholders  and  enables  the  perspectives 
they  require,  at  the  same  time  as  building  reusable  catalogues  of  components,  whether 
these  components  are  technical,  contractual,  organisational,  or  simply  requirements  or 
effectiveness  envelopes  that  occur  throughout  and  across  different  capability  needs 
and  projects. 

The  enabling  platform  for  the  approach  is  a  technical  innovation  within  which  a 
toolset  of  notations  allow  common  elements  to  be  put  together  for  particular  purposes, 
and  where  each  contextual  reuse  of  an  element  contributes  to  a  richer  definition  of 
that  element  when  viewed  across  the  range  of  perspectives  (see  Figure  5).  This 
feature  enables  different  stakeholders  across  the  process  to  be  engaged  on  their  terms, 
but  connected  to  the  work  of  other  stakeholders  at  other  stages. 

Two  key  points  have  arisen  from  our  work  across  the  communications  capability, 
illustrated  here  by  examples  from  Air  Manoeuvre  Command  and  Control  (C2),  one  of 
the  projects  that  the  authors  have  been  working  with  in  the  early  stages  of  CADMID. 

4.2  Support  throughout  the  acquisition  process ,  not  just  at  development  and 
manufacture 

The  development  of  User  Requirements  for  an  Air  Manoeuvre  Command  and  Control 
System  in  the  Land  and  Littoral  environment  requires  understanding  a  range  of 
different  concepts  concerning  the  context  of  operations  and  how  these  fit  together. 

The  approach  that  we  have  taken  involves  recognising  the  concepts  being  used  - 
including  organisations,  defence  tasks  and  capability,  environments,  performance 
profiles  and  so  on  -  and  allowing  these  to  be  captured  directly  in  appropriate  models 
that  allow  the  stakeholders  involved  to  both  express  and  validate  the  concepts  in  a 
familiar  and  accessib 


The  Defence 
Capability 
Framework  (see 
Figure  6)  is  used 
extensively  to 
explore  and 

reconcile  this 
range  of  business 
and  technical 
views. 


e  format. 
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Methodology  support  for  early  engagement  and  structuring  can  include  a  range  of 
approaches,  including: 

4-  Soft  Systems  modelling  to  capture  high-level  concepts  of  capability  objective; 
4-  Performance-oriented  methods  such  as  the  development  of  frameworks  to 
capture  key  effectiveness  criteria  and  needs; 

4-  Modelling  the  principles  of  operation  that  drive  the  rationale  and  begin  to  map 
against  operational  concept  pictures. 

Once  we  have  traced  into  the  operational  concept,  we  can  move  gradually  into  more 
technical  models  concerning  operations,  mapping  into  Systems  and  Technical 
Standards  models  following  the  DoD  AF  methodology. 

The  Air  Manoeuvre  C2  work  has  engaged  a  range  of  stakeholders  in  the  process, 
principally  capability  owners  and  those  experienced  in  operations,  alongside  those 
with  experience  in  the  kinds  of  systems  that  might  be  integrated  into  these  operations. 
The  method  uses  concepts  appropriate  to  this  stage  of  the  dialogue,  allowing 
assumptions  from  past  practice  to  be  challenged,  while  best  practice  knowledge  from 
the  past  is  carried  forward. 

The  process  of  matching  need  against  current  capability  poses  questions  such  as,  “Do 
we  need  to  reconfigure  current  capability  to  match  new  needs?”  and,  by  implication, 
“What  capabilities  do  we  currently  have  that  are  not  matching  needs?”.  For  example, 
in  Air  Manoeuvre  C2  the  availability  of  information  is  a  critical  aspect  of 
effectiveness,  but  to  different  degrees  in  different  contexts.  Expressing  this  need,  and 
being  able  to  map  into  the  various  configurations  and  scenarios  that  satisfy  this  need, 
requires  the  ability  to  move  seamlessly  from,  for  example,  metrics  and  effectiveness 
assertions  to  the  scenarios  and  configurations  of  military  capability  that  support  and 
generate  these  metrics. 

4.3  Integration  across  the  different  perspectives  required  at  each  stage 

At  each  stage  in  the  CADMID  process,  we  find  a  need  for  a  variety  of  methodologies 
and  notations,  and  creating  and  sustaining  coherence  across  this  environment  requires 
more  than  just  traceability.  We  need  the  ability  to  reference  across  the  whole  range  of 
perspectives,  to  achieve  optimal  use  of  existing  resources  within  the  range  of  contexts 
that  exist. 

Put  another  way,  we  need  the  ability  for  “contextual  re-use”  wherein  the  actual  details 
of  how  something  works  is  dependent  upon  the  situation  in  which  it  is  being  applied. 

In  Air  Manoeuvre  C2,  for  example,  technical  notations  such  as  event  sequence 
notations  (as  shown  in  the  “Detailed  Operational  View”  in  Figure  2)  are  required  to 
capture  exact  behaviours  across  logistics  supply  chains;  equally,  less  technical 
notations  are  required  that  express  the  roles  or  competence  models  for  the 
organisations  that  are  involved  across  this  supply  chain,  that  might  in  turn  be 
associated  with  performance  measures  or  effectiveness  envelopes  in  particular 
situations.  The  meta  model  that  the  team  has  been  developing  alongside  other 
initiatives  in  the  UK  includes  the  elements  shown  in  Figure  7. 
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Defence  Architectural  Framework  Meta-Model 


Figure  7.  Elements  of  the  methodology  meta-model:  components  and  summary 


Support  is  given  for  the  core  technical  notations  of  DoD  AF,  but  these  are  simply 
different  views  onto  the  same  elements  described  in  other  perspectives,  where  they 
pick  up  additional  references  and  definition.  Process,  risk,  organisation  and 
effectiveness  are  all  teased  apart,  but  put  back  together  through  referencing  and 
contextual  reuse. 
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In  Air  Manoeuvre  C2,  the  model  layer  that  allows  a  coherent  enterprise  representation 
comprising  multiple  integrated  elements  can  be  seen  and  constructed  from  different 
viewpoints  -  diagrams  provide  a  way  of  reusing  and  configuring  defined,  tested 
components  to  meet  a  particular  need.  So,  an  operational  view  (an  OV-2)  model  (see 
Figure  8)  pulls  together  a  set  of  organisations,  and  is  related  to  a  collection  of 
performance  measures  that  appear  in  their  own  right. 

Applying  this  Blueprint  to  a  variety  of  significant  situations  in  the  UK  defence  sector 
has  resulted  in  the  creation  of  visual  and  formal  requirements  models  closely 
consistent  with  DoD  AF,  and  also  with  the  original  motivation  for  Enterprise 
Architecture.  In  all  cases,  the  models  have  been  created  interactively  with  key 
stakeholders,  motivated  by  the  requirement  for  a  coherent  definition  of  military 
capability  aligned  with  information  and  knowledge  sources.  The  approach  recognises 
that  a  notation  and  toolset  has  to  be  functionally  fit  for  purpose,  but  also  supportive  of 
the  process  itself  -  accessible  to  all  significant  stakeholders,  and  able  to  address  non¬ 
technical  as  well  as  technical  concepts  and  activities. 


5.  Summary  and  Conclusions 

This  paper  has  addressed  areas  in  which  improvements  are  needed  to  address  the 
performance  of  capability  development  within  defence.  Focusing  upon  the  need  for 
more  effective  approaches  to  requirements  modelling  and  stakeholder  participation 
within  large  programmes,  we  have  reflected  upon  the  reasons  behind  current 
difficulties,  and  described  approaches  whereby  these  are  currently  being  combated 
through  our  development  programmes.  We  have  illustrated  how  some  of  these 
proposed  approaches  are  being  pursued  within  the  British  Army. 

In  conclusion,  we  argue  that: 

To  address  the  issues  of  risk,  cost  and  time  over-run  within  defence 
acquisition,  we  need  methodologies  that  better  support  the  early  stages  of  the 
process.  In  particular,  this  support  needs  to  encourage  and  enable  all  of  the 
relevant  stakeholders  to  engage  constructively  during  the  early  stages,  in  such 
a  way  that  they  are  able  to  continue  their  participation  in  a  coherent  manner 
onwards  throughout  the  life  of  a  programme. 

i-  This  means  that  owners  of  capability  requirements  are  able  to,  and  are 

expected  to,  take  a  more  active  and  responsible  role  in  requirement  definition 
and  in  ensuring  alignment  of  solution  to  this  requirement.  Also  that  decision 
makers  throughout  the  process  are  able  to  make  sense  of  their  complex  and 
adaptive  environment. 

i-  Which  in  turn  requires  principles,  notations,  methodologies  and  tools  that  are 
rich  enough  to  express  in  a  coherent  and  integrated  manner  the  perspectives  of 
all  of  these  stakeholders.  By  creating  clarity  and  revealing  insights,  options 
and  implications,  the  wider  community  of  stakeholders  can  be  motivated  to 
perform  to  the  benefit  of  the  programme  objectives. 
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The  concept  of  enterprise  architecture  is  the  key  to  this,  but  the  approach  adopted 
must  provide  the  required  breadth,  integrity  and  accessibility  to  enable  all 
stakeholders  to  engage  and  remain  engaged  in  an  active  manner,  across  the  range  of 
perspectives  demanded  by  each  stage  in  the  acquisition  process.  This  is  consistent 
with  the  original  vision  of  enterprise  architecture,  but  at  odds  with  the  primarily 
technical  approach  promoted  through  DoD  AF.  Through  developing  improved 
methodologies  and  architecture  frameworks,  and  applying  these  to  capability 
development  within  UK  defence,  we  contribute  towards  delivering  the  benefits 
envisaged  by  the  Strategic  Defence  Review. 
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Reports: 

Improvements  in  gross  time  and  cost  overrun 

Encouraging  signs  of  innovative  relationships 
with  industry  ... 

But ... 

there  is  more  to  do 
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‘More  needs  to  be  done’ 


TlHE 

Salamander 
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•  Methodologies,  architecture  and  governance 
frameworks  for: 

4-  Defining  and  managing  requirements 

4-  De-risking  development  through  increased 
coherence,  integration  and  communication 


•  Engaging,  motivating  and  improving  the 
performance  of  stakeholders  in  the  acquisition 
community  through: 

4- Transparency 
4-  Incentive 
4- Communication 
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ied  to  define  capabi 


To  encourage  a  mind-set  that  is  unencumbe 
developments,  it  is  important  that  the  initial  ( 
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Organisational 

considerations 


Technical 

considerations 


People  & 

training 

considerations 


Performance 

considerations 


ons 


A  number  of  considerations  apply  throughout  the  process, 
each  within  the  sphere  of  interest  of  one  or  more  stakeholders. 


The  balance  of  effort  given  to  these  considerations  throughout  the  process  is  important, 
to  enable  continuing  engagement  with  stakeholders. 


Stakeholders: 
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•  Action  at  both  the  business  and  technical  level 

•  An  increased  awareness  that  these  views  are 
closely  related 
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Challenges 

•  Creating  a  common  language  to  enable  the 
effective  engagement  of  stakeholders 

•  The  development  of  a  common  approach  to  their 
description  with  tools  in  support 
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Capability  Requirement 


Viewed  at  the  60,000  foot 
perspective,  we  are  aware  of 
the  overall  context  of  the 
requirement,  and  the 
principal  participating 
components 


The  Operational  Concept  of  Conduct  Joint  Force  Targeting 


Viewed  at  the  6  foot 
perspective,  we  are  able  to 
analyse  the  specific 
interactions  required  between 
specific  components  in  order  to 
achieve  connectivity  and 
synchronisation 


USCENTCOM  Targeting  MEA  OV-6c 


JFC  Node  JFACC  Node  MAW  Node  WOC  N< 


of  activities  to  op 


The  challenge  is  to  ensure  integrity,  breadth  and  completeness 
of  these  views,  to  inform  and  connect  a  broad  community  of 
stakeholders  actively  throughout  the  programme 
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Challenges 

•  Creating  a  common  language  to  enable  the 
effective  engagement  of  stakeholders 

•  The  development  of  a  common  approach  to  their 
description  with  tools  in  support 

•  Managing  communication  and  relationships 

•  Managing  performance  and  achievement 
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•  Requirements  definition  is  conditioned  by 
current  and  past  assumptions 

•  The  coverage  of  key  areas  within  acquisition 
stages  is  often  unbalanced 

•  Application  of  enterprise  architecture 
methodology  over-emphasises  the  technical 

•  The  social  and  economic  realities  are  often 
neglected 
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•  Principles  and  ideas 
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ORGANIZATION 


•  Principles  and  ideas 

•  Support  throughout  the  acquisition  process  not 
just  at  development  and  manufacture 
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ORGANIZATION 


•  Principles  and  ideas 

•  Support  throughout  the  acquisition  process  not 
just  at  development  and  manufacture 

•  Integration  across  the  different  perspectives 
required  at  each  stage 
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Making  Sense  of  Complexity 

Conclusions 

•  To  address  the  issues  of  risk,  cost  and  time  over-run, 
we  need  methodologies  that  better  support  the  early 
stages  of  the  process 

•  Owners  of  capability  requirement  need  to  be  able  to 
(and  be  expected  to)  take  a  more  active  and  responsible 
role  in  requirement  definition  and  solution  alignment 

•  Decision  makers  throughout  the  process  must  be  able  to 
make  sense  of  their  complex  adaptive  environment 

•  This  requires  principles,  notations,  methodologies  and 
tools  that  are  rich  enough  to  express  in  a  coherent  and 
integrated  manner  the  perspectives  of  all  the 
stakeholders  . . . 
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